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AUTOMATED DEVELOPMENT SYSTEM 
FOR DEVELOPENG APPUCATIONS THAT 
INTERFACE WITH BOTH DISTRIBUTED 
COMPONENT OBJECT MODEL (DCOM) 
AND ENTERPRISE SERVER 
ENVIRONMENTS 

CROSS REFERENCE TO CO-PENDING 
APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Ser. No, 09A64,932, filed Oct. 1, 1988. entitled "A 
MULTI-CUENT USER CUSTOMIZED DCOM GATE- 
WAY FOR AN OLTP ENTERPRISE SERVER 
APPUCAnON'\ and appUcation Ser. No. 09/164,759, filed 
Oct. 1, 1998, entitled "A COMMON GATEWAY WHICH 
ALLOWS APPLETS TO MAKE PROGRAM CALLS TO 
OLTP APPLICATIONS EXECUTING ON AN ENTER- 
PRISE SERVER", both of which arc assigned to the 
assignee of the present invention and incorporated herein by 
reference. 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates to a communications gate- 
way for providing access to an enterprise server application 
from a Distributed Component Object Model (DCOM) 
environment, and more specifically, to a gateway utility 
which provides an interactive interface to simplify the 
building of functions to access an enterprise On-line Trans- 
action Processing (OLTP) apphcation from a DCOM envi- 
ronment. 

2. Description of the Prior Art 

The methods by which companies conduct business with 
their customers are undergoing fundamental changes, due in 
large part to World Wide Web technology. In addition, the 
same technology that makes a company accessible to the 
world, may be used on internal company networks for 
conducting operational and administrative tasks. 

One of the technologies underlying the World Wide Web 
is the Web Browser. Web Browsers have become a de facto 
user interface standard because of their ability to interpret 
and display information having standard formats (e.g., 
HyperText Markup Language (HTML), standard test, GIF. 
etc.). CUent software programs, popularly referred to as Web 
Browsers (e.g.. Mosaic, Netscape Navigator, Microsoft 
Internet Explorer, etc.), execute on client systems and issue 
requests to server systems. The server systems typically 
execute HyperText Transport Protocol (HTTP) server pro- 
grams which process requests from the Web Browsers and 
deliver data to them. The system that executes an HTTP 
server program and returns data to the Web Browser will 
hereinafter be referred to as a Web Server System. An HTTP 
server program itself will be referred to as a Web Server. 

A Web Server System has access to on-line documents 
that contain data written in HyperText Markup Language 
(HTML). The HTML documents contain display 
parameters, capable of interpretation by a Web Browser, and 
references to other HTML documents and Web Servers 
(source: World Wide Web: Beneath the Surf, from UCL 
Press, by Mark Handley and Jon Crowcroft, on-line at 
http://www.cs.ucl.ac.uk/stafi^on/book/book.html). 

As Web Browsers are making their mark as a "standard" 
user interface, many businesses have a weahh of information 
that is managed by prior art data base management systems 
such as DMS, RDMS, DB2, Oracle, Ingres, Sybase, 
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Informix, and many others. In addition, many of the data- 
base management systems are available as resources in a 
larger transaction processing system. There are also mission 
critical applications which still reside on enterprise servers, 
since these type of systems have resiliency and recovery 
features historically not available on other smaller types of 
servers. 

One key to the future success of a business may lie in its 
ability to capitalize on the growing prevalence of Web 
Browsers in combination with selectively providing access 
to the data that is stored in its databases. Common Gateway 
Interface programs are used to provide Web Browser access 
to such databases. 

The Common Gateway Interface (CGI) is a standard for 
interfacing external applications, such as Web Browsers, to 
obtain information from information servers, such as Web 
Servers. The CGI allows programs (CGI programs) to be 
referenced by a Web Browser and executed on the Web 
Server system. For example, to make a UNIX database 
accessible via the World Wide Web, a CGI program is 
executed on the Web Server system to transmit information 
to the database engine, receive the results from the database 
engine, and format the data in an HTML document which is 
returned to the Web Browser. 

A disadvantage with the CGI program approach described 
above is that the application developer must be intimately 
acquainted with the HTML, the CGI, and the database 
engine. In addition, a different CGI program may be required 
for each different database, thus adding to the cost of 
creating and maintaining the database access for the Web 
Browser. Thus, the application developer is required to 
understand multiple types of systems, and must also under- 
stand how these systems interface. The learning curve for 
this type of development is therefore undesirably long. 

SUMMARY OF THE INVENTION 

The present invention overcomes many of the disadvan- 
tages associated with the prior art by providing a utility with 
an interactive interface that simplifies building transaction 
gateway functions to access an enterprise server based 
On-Line Transaction Processing (OLTP) application from a 
Distributed Component Object Model (DCOM) environ- 
ment. Thus, the automated development system of the 
present invention allows developers to more easily incorpo- 
rate functionality from enterprise-based applications within 
an application running on a DCOM-based platform. 

In order to utilize the present invention, a developer must 
first create a service on the enterprise server. An example of 
a service may be retrieval of data from a database associated 
with the enterprise On-Line Transaction Processing (OLTP) 
system. After the service has been developed, the developer 
transfers the service input and output "view files" to a 
location where they can be accessed by the DGateAce utility 
of the present invention. In a preferred embodiment, this 
location is a Windows NT workstation. The "view files" 
contain a description of the parameters used for transaction 
requests and responses. In other words, the input view file 
includes information on what the input parameters are and 
how they must be formatted for the service, and the output 
view file includes information on what the output parameters 
are and how they are formatted by the service to the external 
user. A single view file could be used for both the input and 
output parameters for a transaction, separate view files could 
be used for both input and omput parameters, or a single 
view file could be used for only input parameters. 

Upon invocation, the DGateAce utility extracts the inter- 
face information from the view files and automatically 
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generates a source fi]e that is compatible with the DCOM shows interrelationship between interactive user queries and 
enviro anient. This source file is subsequently used in the the function definition, 
creation of a DCOM Server. During the source file genera- 
tion process, the DGaleAce utilily queries the user for the DETAILED DESCRIPTION OF THE 
type of client(s) that will be using the Server so that the 5 PREFERRED EMBODIMENTS 
Server is tailored for receiving requests from those types of « , , , , • • , . . r ,1 
Oicnts. These Clients may include N^isual Basic, C++, Web ^he detailed descnpUons which foUow are presented 
Browsers with Active Server Pages (ASPs), or other types of ^^^S^^V ^^^^^ algpnthms and symbohc representations 
Client applications. After the DCOM Server has been sue- of operations on data bits within a computer memory. These 
cessfully generated, the developer must then develop an algorithmic descriptions and representations are the means 
application (Client) running within the DCOM environment. ^° used by those skilled in the data processing arts to most 
When a standard call is made firom a DCOM Client appli- effectively convey the substance of their work to others 
cation to an enterprise-based On-Line Transaction EProcess- skilled in the art. 

ing service, the following steps will occur: First, the request An algorithm is here, generally, conceived to be a self- 
will pass firom the DCOM Client to the DCOM Server. The consistent sequence of steps leading to a desired result. 
Server will correctly format (pack) the request parameters, These steps are those requiring physical manipulations of 
and pass the request onto the DGate_Server.dll Dynamic physical quantities. Usually, though not necessarily, these 
Link Library (DLL). The Dynamic Link Library (DLL), quantities take the form of electrical or magnetic signals 
verifies that the input parameters can be read, and verifies capable of being stored, transferred, combined, compared, 
that the output parameters can be written. The DLL then and otherwise manipulated. It proves convenient at times, 
appends required additional parameters to the request and principally for reasons of common usage, to refer to these 
forwards the request to the DGate.Exe (the DCOM signals as bits, values, elements, symbols, characters, terms, 
Gateway) component. This DCOM Gateway executable numbers or the like. It should be kept in mind, however, that 
uses parameter information to correctly forward the request all of these and similar terms are to be associated with the 
to the OLTP service on the enterprise system. The requested appropriate physical quantities and are merely convenient 
service is performed on the enterprise system, and a labels appHed to these quantities. 

response is sent back to the DCOM Gateway executable Furthermore, the manipulations performed are often 

(DGate.Exe). The DCOM Gateway executable checks for referred to in terms, such as adding or comparing, which are 

successful completion by the OLTP service, then passes the commonly associated with mental operations performed by 

response to the Server, which correctly formats (unpacks) a human operator. No such capability of a human operator 

the data and passes it back to the requesting Ghent appli- ^ necessary, or desirable in most cases, in any of the 

cation. operations described herein which form part of the present 

Inthismanner, a C, C++, Visual Basic, or some other type invention; the operations are machine operations. Useful 

of application running on an NT or Windows system is machines for perfonoiing the operations of the present inven- 

provided access to user-developed services mnning on an tion include general purpose digital computers or other 

enterprise server. The developer does not need to understand similar devices. In all cases, it should be kept in mind the 

the interface between the two systems because this infor- distinction between the method operations in operating a 

mation is automatically included within the automatically- computer and the method of computation itself. The present 

generated interface software components. invention related to method steps for operating a computer 
BRIEF DESCRIPTION OF THE DRAWINGS 40 ^ processing electrical or other (e.g., mechanical, chemical) 

^ L ^. ^ . . . , ^ . physical signals to generate other desired physical signals. 

Other objects of the present invention and many of the 1^ . . 

attendant advantages of the present invention will be readily , P'f '^^^'^ ^° "PP^f ^ P^'' 

appreciated as the same becomes better understood by operations. This apparatus may be specially 

reference to the foUowing detailed description when con- ^^o^^^^t^d for the required purposes or it may comprise a 

sidered in comiection with the accompanying drawings, in fneral purpose computer as selectively activated or recon- 

which like reference numerals designate like parts thr^gh- figured by a computer program stored m the computer. The 

out the figures thereof and wherein: algorithms present herein are not mherently related to a 

ni-. -11 * r.L - . L- 1. particular computer system or other apparatus. In particular, 

FIG. 1 is an illustration of the environment withm which ^ > 1 . f i_ j -.i. 

- . , various general purpose computer systems may be used with 

the present mvention operates; .„ .^^ ^, . 

J^^ ^ . ^. , , , , . 50 computer programs written m accordance with the teachmgs 

FIG. 2 is a high-level, generahzed diagram showing of the present invention, or it may prove more convenient to 

mputs to and outputs from the fiinction buildmg tool ^^^^^^^^^ ^^^^ specialized apparams, to perform the 

(DGateAce) of the present mvention; ^^^^^^^ method steps. The required stmcture for such 

FIG, 3 lUustrates how Interface Defimtion Language machines will be apparent from the description given below. 

(IDL) files generated by the function buUding tool of the 33 ^ ^ illustration of the environment within which 

prcscm invention (DGateAce) arc compiled by the the present invention operates. As described in more detail 

Microsoft lUL compUer. ^^^j^^^ present invention is an automated development 

FIG. 4 illustrates how the output files from the fimction ^ys^em which simpUfies the creation of DCOM Client/ 

buildmg tool (DGateAce) of the present invention are used server components which interface an application running 

durmg the compilation and hnking of the DCOM Server ^^jer the DCOM environment with an enterprise based 

, , On-Line Transaction Processing (OLTP) service. The 

FIG. 5 is a diagram which indicates the interrelationships present invention is specifically developed to operate in the 

between the DGale gateway and DGateAce tool; oGate environment described in a co-pending appUcation 

FIG. 6 is a generahzed flow diagram of the process flow entitled, "A MULTI-CLIENT USER CUSTOMIZED 
of the function buiUing tool (DGateAce); and 65 DCOM GATEWAY FOR AN OLTP ENTERPRISE 

FIG. 7 is a detailed flow diagram of the process flow of SERVER APPUCATION", which is hereby incorporated by 

the function building tool (DGateAce), which specifically reference. 
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Open/OLTP services 150 are created by a user on an DGate-Server.dll 168. The DGate-Server.dll 168 and the 
enterprise server 152, such as a Unisys 2200. These services DGate.exe 166 are the modules which "DCOM-enable" an 
150 are capable of operating under an OLTP-style transac- OLTP enterprise server 152 such as the Unisys 2200 System, 
tion processing system. In a preferred embodiment, this FIG. 2 is a high-level, generalized diagram showing 
OLTP-style system is X/Open compliant. The service 150 is 5 inputs to and outputs from the function building tool 
designed to accomplish a specific task, for example, update (DGateAce) of the present invention. The DGateAce tool 
a user's bank account balance following a debit or credit. 226 is a transaction gateway utility thai provides an inter- 
Each service is associated with an input view (.v) file 158 active interface which simplifies the building of functions 
which defines how the input parameters will be provided to within a Distributed Component object Model (DCOM) 
the service 150. In particular, the .v file 158 indicates where environment for accessing an enterprise based On-Line 
each input parameter is located in the view file, and the size Transaction Processing service. The DGateAce tool 226 can 
and type of each input parameter. If a service 150 is to run on any platform that supports the Microsoft Windows 95 
provide output to the user (for example, the updated account or Microsoft Windows NT envirormaent and has access to 
balance), another output view file is required to communi- files containing VIEW buffers for the transactions that are 
cate how the information will be presented within the output 15 going to be converted. DGateAce 226 receives input from 
view buffer. four sources: a function template 200, one or more view 
For all services 150 that are to accessed from a particular ^^^^^ ^^^^ ^02, a universal unique identifier from a UUID 
Windows NT node 190. the associated view files 158 must generator 210, and a set of interactively entered information 
be copied (via FTP or other copy service, shown at 159) to generated by an application developer 214. From these four 
that node 190. Once the view files 158 have been success- input sources, DGateAce produces two types of output: 
frilly copied to the Windows NT node 190, the ViewC interface definition language (IDL) files 222, and function 
compiler 160 is used to generate ".w" files 162. 224. 

The PathMate DGateAce software component of the One of the tasks when developing an enterprise based 

present invention also must have access to the view files Open/OLTP service is defining view buffer files 202. A view 

158. DGateAce 172 uses the view files 158 to automatically ^^^^ 202 is a description of the parameters used for 

generate files needed for an application to operate within a transaction requests and responses. A single view buffer file 

DCOM environment. These files include the DCOM Server 202 could be used for both the input and output parameters 

Applcation.exe 170, the Stub.dU 182, and the Proxy.dll 184. for * transaction, or separate view buffer files 202 could be 

The Distributed Component Object Model pCOM) is a 33 ^""^ i°P^^ ^^^P^^' 

Microsoft model for distributed object computing. Within ^h^ DGateAce tool of the present invention uses the 

the DCOM environment, a remote DCOM Qient Applica- Open/OLTP view buffer files (.v) 202 to allow developers to 

tion 186 can make a request. The DCOM cUent 186 can be select the views they want to use when defining the functions 

any type of client, including a Visual Basic client, a C++ ^ given DCOM server program. Therefore, these view 

cUent, or a Web Browser with Active Server Pages (ASP). If 35 ^^^^^ ^^^^ accessible from the workstation 208 

the request made by the DCOM client 186 is a request for where PathMate 228 is instaUed, either on a local drive or on 

access to a remote process (interprocess request) the request * network drive accessible from the PathMate workstation 

is routed to proxy.dll 184. Proxy.dll 184 is a code segment 208. 

which receives any client requests targeted for a remote DCOM requires that each interface have a universal 
server, and will facilitate the necessary interprocess com- 4Q unique identifier (UUID). DGateAce 226 can use its UUID- 

munications. The proxy.dll 184 understands how to com- GEN utility 210 to generate and insert a UUID for an 

municate with the Client 186, and also understands how to interface with the click of a button. If the Open/OLTP 

communicate over an interface 185 which is shared by two Pathway is not installed, a UUID does not have to be entered 

or more processes. The proxy.dll 184 "marshals" the request in DGateAce 226, but can be manually entered later in the 
parameters into an independent format so that they may be 45 IDL file 222, before compilation. 

provided by the client process 186 over the COM-based DGateAce 226 also requires a function template 200, such 
interface 185, which conforms with the Microsoft DCOM as the one provided with DGateAce 226. which provides 
Model. The stub.dll 182, which also understands how to DGateAce 226 with a generalized framework for the gen- 
communicate over the common interface 185, "un- eration of an output fiinction file 224. A customized function 
marshals*' the parameters into a format that can be under- template can be used in place of the template provided by 
stood by the DCOM Server Application.exe 170. Thus, the DGateAce 226. 

DCOM environment allows machines with entirely different Finally, DGateAce 226 requires a set of information 

architectures (PCs, Workstations, etc.) to communicate which is interactively provided by an application developer 

using a common interface. 214 during the DGateAce 226 generation process. This set 
The specifics of the common interface are described in an 55 of information includes interface names and function names. 

Interface Definition Language (IDL) 174. The IDL 174 is As mentioned earlier, the DGateAce tool 226 will produce 

operated on by the Microsoft Interface Definition Language Interface Definition Language (IDL) files 222 as output. 

(MIDL) compiler 176 to create a set of .c (Q and .h (header) These IDL files 222 are source files defining the interface for 

files 178. Then, a second compiler (C++) 180 operates on the a DCOM application. After generation of the IDL files 222 
.c and .h files to create the stub.dll 182 the proxy.dll 184, and 50 by the DGateAce tool 226, the IDL files are compiled to 

the DCQM Server Application executable (.exe) 170. The produce a proxy/stub source file used by the DCOM Client/ 

proxy.dll 184 is linked to the DCOM Client Application Server application, a UUID source file, and a set of header 

executable (.exe) 186, and the stub.dll 182 is linked to the files. 

DCOM Server Application executable (.exe) 170. xhe DGateAce tool 226 also produces fimction files 224 
Once the stub.dll 182 un-marshals the parameters, the 65 as output from its generation process. These function files 

parameters are packaged into a single buffer by DCOM 224 server as source files for modules of the DCOM Server 

Server Application executable (.exe) 170 and passed to the apphcation. There is typically one function file 224 gener- 
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ated for each unique combination of Open/OLTP service parameters will be provided to the service. In particular, the 

name, input view buffer, and output view buffer. view files 516 and 518 indicate where each iEq)ut/outpul 

FIG. 3 illustrates how Interface Definition Language parameter is located, and the size and type of each input/ 

(IDL) files generated by the function building tool of the output parameter. 

present invention (DGateAce) are compiled by Ihe 5 After the input and output view files 516 and 518 have 

Microsoft IDL compiler. As described previously in FIG. 2, been transferred to a location where DGateAce 506 can 

DGateAce 226 produces two types of output files: function operate on them, DGateAce 506 extracts the interface infor- 

files and Interface Definition Language QHh) files 300. mation from the view files 516 and 518 and automatically 

Interface Definition Language (IDL) files 300 are source generates a source file that is compatible with the DCOM 
files which define the interface for the DCQM application. 1° environment 500. This executable file is shown in FIG. 5 as 

After generation of the DOL files 300 by the DGateAce the DCOM Server 510. During the generation process, 

utility, the IDL files are provided as input through interface DGateAce 506 queries the user 508 for the type of Client(s) 

302 to a Microsoft Interface Definition Language (MIDL) 504 which will be using the Server 510 so that the Server 

compiler 304, which must be installed on the development 510 is tailored for receiving requests from those types of 

workstation. The MIDL compiler 304 is included as part of Clients 504. These Clients 504 may include Visual Basic, 

the Microsoft Windows Software Development Kit (SDK). C++, and/or Web Browsers with Active Server Pages 

The MIDL compiler 304 produces four types of output files. (ASPs). 

The first type of output file is the proxy/stub source file 314. The developer must next develop the application (Client) 

The proxy/stub source file 314 includes a proxy function for 504 running within the DCOM environment which gener- 

the DCOM client and a stub fimction for the DCOM Server. ates the request. This application (Qient) 504 will include a 

The second type of output file is an interface UUID source standard call 522 to the Server 510. 

file 318. An interface UUID source file 318 provides UUIDs when a standard call 522 is made from an application 504 

for the DCOM client program. The third type of output file running under DCOM to the DCOM Server 510, the Server 

produced by the MIDL compiler 304 is a header file 316. 510 will correctly format (pack) the request parameters, and 

The header file (.h) 316 is used in the compilation of the pass the formatted parameters via interface 526 to the 

DCOM Client and Server source code. Finally, the last file DGate_Server.dll Dynamic Link Library (DLL) 512. The 

produced by the MIDL compiler 304 is a ddldata.c file 320. qll 512 verifies that the input parameters can be read, and 

The ddldata.c file 320 provides the proxy/stub with entry- verifies that the output parameters can be written. The DLL 

point infonnation. 512 then appends additional parameters to the request and 

FIG, 4 illustrates how the output files from the ftinction forwards the request to the DGate.exe component 514 via 

building tool (DGateAce) of the present invention are used interface 528. DGate.exe 514 uses parameter information to 

diuing the compilation and linking of the DCOM Server correctly forward the request to the 2200 enterprise system 

module 432. In order to successfully compile and link the 502. The requested service 520 is performed on the 2200 

components of the DCOM Server 432, a C or C++ compiler enterprise system 502, and a response is sent back to 

410 and object linker 428 must be installed on the devel- Dgate.exe 514 via interface 532. DGate.exe checks for time 

opment workstation. There are three major input compo- out or disconnect conditions and returns the service response 

ncnts provided to the C or C++ Compiler 410; 1) source via interface 528 to the DGate__Server.dll 512. The DGate_ 

code for the main program of the DCOM server application, Server.dll 512 checks for successful completion of the 

written by the developer 400, 2) the function files 224 operation and passes the response to the Server 526 via 

produced by the DGateAce tool, as shown in FIG. 2, and 3) interface 526. The Server 526 checks completion codes and 

The header file 316 produced by the MIDL compiler, as passes the response to the requesting client 504 via interface 

shown in FIG. 3. The outputs of the C or C++ Compiler 410 522. 

are an object file (.obj) for the main program 420 and a set Iq this manner, a C, C++, Visual Basic, or some other type 
of object files (.obj) for the fiinctions 416. These two object of application 504 running on a Microsoft Windows NT or 
files 420 and 416 are then linked with the DGate Server Microsoft Windows 95 system is provided access to user- 
library file (DGate_Server.lib) 418 through the Unker mod- developed services 520 running on an enterprise server 502. 
ule 428 to create the DCOM Server executable program 432. -rhe developer does not need to understand the interface 

FIG. 5 is a diagram which indicates the interrelationships between the two systems 500 and 502 because this infor- 
betwcen the DGate gateway and DGateAce tool. The auto- jq mation is automatically included within the automatically- 
mated development system the of present invention allows generated interface software components, 
developers to develop applications, or "services", on an pjc g 3 generalized flow diagram of the process flow 
enterprise server. In this case, OLTP applications are devel- ^^e ftinction building tool (DGateAce). After' the 
oped on a Unisys 2200 enterpnse system 502. Ideally, these DGateAce tool starts, it first displays a DGateAce: DCOM 
applications will be available to end users executing within 55 interface Definition Form 602. This form 602 is used to set 
a DCOM environment 500. interface definition for the Server. A user will supply 

Under the development system of the present invention, a data 608 for this form by providing the following types of 

developer must still understand how to create a service on information: IDL header infonnation, gateway name, inter- 

the enterprise system 502. An example of a service may be face name, transaction type, data type, and selection of a 
retrieval of data from a database associated with the 2200 50 template file 618. This user supplied input data 608 is passed 

enterprise On-Line Transaction Processing System (OLTP) onto both the module which retains interface user input for 

520. later file generation 600, and the module which retains 

After a developer has completed development of a service ftinction specific user input for later file generation 634. 

520 on the Unisys 2200 system 502, the developer transfers When the user selects a template file 618, the template file 
the service input 516 and/or output view files 518 to a 65 618 is also passed onto the module which retains interface 

locations where they can be accessed by the DGateAce tool specific user input for later file generation 600, along with 

506. The view files 516 and 518 define how the input any appropriate template data 620. 
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UpoD completion of the interface specific user screen 602, 
the DGateAce tool advances to the DGateAce: DCOM 
Function Definitions form 622. Hiis form 622 is used to 
build functions for the interface. On this form a developer is 
queried to input the required service name for the transaction 
to be translated to DCOM/OLE. The developer is also 
prompted for the input and output (optional) view file 
locations, and the OLTP input and output views the devel- 
oper wants included in the fiinction. Finally, the developer is 
asked to provide select function -based attributes. A devel- 
oper provides this input data 628 to the module which retains 
function specific user input for later file generation 634. 
Information may also be passed to the module which retains 
function specific user input for later file generation 634 from 
the module which retains interface specific user input for 
later file generation 600. 

Upon completion of processing of the interface specific 
and function specific input data, control next passes to a 
module which generations output file pairs based on the user 
provided input 636 via interface 632. This module 636 will 
generate one pair of output files for each interface specified 
644. The pair of output files includes a code (functions) file 
642 and an Interface Definition Language (IDL) file 646. 

FIG. 7 is a detailed flow diagram of the process flow of 
the function building tool (DGateAce), which specifically 
shows interrelationship between interactive user queries and 
the function definition. The DGateAce tool behaves like a 
wizard, prompting the developer for information it needs to 
build base server source code files or modules that call 
TransIT Open/OLTP transactions. The DGateAce tool 
prompts the developer through three data input forms: a 
DCOM Interface Definition form 704, a Function Defini- 
tions form 732, and a DCOM Functions Summary form 762. 
The DGateAce tool creates and saves Interface Definition 
Language (IDL) files 712 and function definition files 766. 
These files are the basis for the DCOM Client and Server 
code modules access by the DGate feature in the WebTX 
product. The DGate feature is packaged with the WebTX 
product as part of the Integrated Operating Environment 
(lOE) and is installed on the Windows NT node of a Unisys 
ClearPath IX Server, The DGateAce tool is packaged with 
the PathMate product as a solution. 

In order to successfully run the DGateAce utility, the 
utility needs access to certain files locally or through net- 
work connections to a workstation. A developer must 
specify the location of the OLTP view buffers, otherwise 
known as "view files" (not shown), specify the location of 
any custom function templates 702 associated with the 
client/server function code files, and be able to save the 
DGateAce generated IDL files and fiinaion definition files 
712 and 766. 

After starling the DGateAce tool, a user is first presented 
with a DCOM interface definition form 704. This form will 
prompt the user to enter IDL header information, a gateway 
name, interface name, transaction type, data type, and a 
template file. Upon completion of the interface definition 
form 704, a user is presented with several choices. The user 
may choose to exit the tool 710, without saving any of the 
information. The user may decide to utilize the browse 
function 726 from the "open/save as common dialog" 744 to 
select a function template file. The user can also choose to 
save the IDL file 712 via the open/save as common dialog 
744. Finally, a user may wish to proceed to the next step in 
the definition process, namely building functions 724. If a 
user chooses to continue to the build functions 724 portion 
of the DGateAce tool, the developer is next presented with 
the DCOM Function Definitions form 732. On this form 732 
the developer is prompted to input the required OLTP 
service name for the transaction to be translated to DCOM/ 
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OLE, to select input and output view file locations, to choose 
the OLTP input and output views that are to be included in 
the function, and to select function-based attributes. The 
user may choose browse 740 to select input and output view 
files via the "open/save as common dialog" 744, 

Once the user has provided the necessary input to the 
DCOM function definitions form 732, the user may build the 
function 738. A developer advances to the DCOM Functions 
Summary form 762 when the developer clicks the build 
function 738 pushbutton and answers "NO" to a message 
asking if the developer wishes to build another function on 
the DCOM Function Definitions Form 732. From within the 
DCOM Functions Summary Form 762, a developer may 
return to the DCOM Function Definitions Form 732 by 
choosing the "OK" pushbutton 758, display all of the 
functions defined for the current function file in a list box, 
"ADD" 770 or "DELETE" 772 the individual functions 
created by the DGateAce tool, or save the function definition 
766 via the "open/save as common dialog" 744, By clicking 
the "ADD" pushbutton 770, the process flow will return to 
the DCOM Function Definitions Form 732, so that the 
developer can create another function for the current func- 
tion file. 

In order to verify that the DGateAce tool successfully 
wrote the interface definition and function definition files, 
the developer may open Explorer under Microsoft Windows 
95 to see that the Interface Definition Language (IDL) files 
and source code (.c) files exist in the appropriate directory 
and file name locations, and may also verify that the date and 
time stamps on the files are current. To verify that the 
DGateAce tool generated the proper code, the Interface 
Definition Language (IDL) code can be used as a function 
prototype for the C++ wizard and the source files (.c) should 
successfully compile with the C/C++ compiler. 

Having thus described the preferred embodiments of the 
present invention, those of skill in the art will readily 
appreciate that the teachings found herein may be applied to 
yet other embodiments within the scope of the claims hereto 
attached. 

What is claimed is: 

L In a data processing system having a Distributed 
Component Object Module (DCOM) environment con- 
nected to an enterprise On-Linc Transaction Processing 
(OLTP) system, the improvement comprising: 

means coupled to said DCOM environment for building a 
set of functions which allow an application residing 
within said DCOM environment to access an associated 
service on said On -Line Transaction Processing 
(OLTP) system; 

wherein an application residing on said enterprise 
On-Line Transaction Processing (OLTP) system has an 
associated set of input and output view files which 
define how parameters will be provided to and received 
from said OLTP system; 

wherein said view files indicate where each said param- 
eter is located in the view file, and the size and, type of 
each said parameter; and 

wherein said view files are copied from said enterprise 
OLTP system to said DCOM environment prior to 
invocation of said function building means. 

2. A data processing system according to claim 1 wherein 
said function building means extracts interface information 
from said view file and generates a set of source files which 
is compatible with said DCOM environment, 

3. A data processing system according to claim 2 wherein 
during said generation of said source files, a user is queried 
about a type of client that will be using said source files, 
thereby allowing said source files to be specifically tailored 
to receive requests from the type of client specified by the 
user. 
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4. A data processing system according to claim 3 wherein 
said set of generated source files includes Interface Defini- 
tion Language (I^L) files which define an interface for a 
DCOM Client application. 

5. A data processing system according to claim 4 wherein ^ 
said IDL files are compiled by a Microsoft Interface Defi- 
nition Language (MIDL) compiler, which produces a set of 
MIDL output files. 

6. A data processing system according to claim 5 wherein 
said set of MEDL output files includes at least one proxy/stub 
source file that has a proxy function for use with said DCOM lO 
Client application, and a stub function for use with a DCOM 
Server. 

7. A data processing system according to claim 5 wherein 
said set of MIDL output files includes an interface Universal 
Unique Identifier (UUID) source file that provides UUIDs ^ 
for said DCOM Client apphcation. 

8. A data processing system according to claim 5 wherein 
said set of MIDL output files includes at least one header file 
that is used in the compilation of said DCOM Client 
application and a DCOM Server. 

9. A data processing system according to claim 5 wherein 
said set of MIDL output files includes a Dynamic Data Link 
(DDL) data file which provides entry point informatioD to a 
proxy function and a stub function. 

10. A data processing system according to claim 3 
wherein said set of source files includes function files which 25 
are moduie source files for a DCOM Server application. 

11. A data processing system according to claim 10 
wherein there is one said function file for each unique 
combination of Open/OLTP service name, input view buffer, 
and output view buffer. 30 

12. A data processing system according to claim 3 
wherein inputs used to generate said source files include a 
function template, Open/OLTP service names from an Open/ 
OLTP application, said view files, a set of interface names 
and function names provided by the user, and a set of 35 
Universal Unique Identifiers (UUIDS) produced by a UUID 
generator in an Open/OLTP gateway. 

13. A data processing system according to claim 3 
wherein said type of chent is a Visual Basic client. 

14. A data processing system according to claim 3 
wherein said type of cfient is a C++ application client. 

15. A data processing system according to claim 3 
wherein said type of client is a Web Browser with Active 
Server Pages (ASPs). 

16. A data processing system according to claim 3 
wherein a client apphcation running within the DCOM 45 
environment includes a standard call to a DCOM Server 
application. 

17. A data processing system according to claim 4 
wherein said enterprise OLTP system is a Unisys 2200 series 
mainframe computer. 50 

18. An apparatus for the automated development of a set 
of functions which allow an application residing within a 
Distributed Component Object Module (DCOM) environ- 
ment to access an associated service located on an enterprise 
On -Line Transaction Processing (OLTP) system having: 

at least one view file residing on said enterprise OLTP 
system which defines how parameters will be provided 
to and received from said OLTP system; 

a file transfer mechanism to move said view file from said 
OLTP system to said DCOM environment; 50 

an automated development utility which will operate on 
said view file to produce at least one output source file 
used in the creation of DCOM Client/Server applica- 
tions; and 

wherein said automated development utility will query a 65 
user about a type of cHent that will be using said source 
files, thereby allowing said output source files to be 



specifically tailored to receive requests from the type of 
client specified by the user. 

19. An apparatus according to claim 18 wherein said 
output source files include Interface Definition Language 
(IDL) files which define the interface for a DCOM Client 
application. 

20. An apparatus according to claim 19 wherein said IDL 
files are compiled by a Miaosofl Interface Definition Lan- 
guage (MIDL) compiler, which produces a set of MIDL 
output files. 

21. An apparatus according to claim 20 wherein said set 
of MIDL output files includes at least one proxy/stub source 
file that has a proxy function for use with said DCOM Client 
apphcation, and a stub function for use with a DCOM 
Server. 

22. An apparatiis according to claim 20 wherein said set 
of MIDL output files includes an interface Universal Unique 
Identifier (UUID) source file which provides UUIDs for said 
DCOM Client apphcation. 

23. An apparatus according to claim 20 wherein said set 
of MIDL output files includes at least one header file that is 
used in the compilatioo of said DCOM Chent apphcation 
and a DCOM Server. 

24. An apparatus according to claim 20 wherein said set 
of MIDL output files includes a Dynamic Data Link (DDL) 
data file which provides entry point information to a proxy 
fiinction and a stub function. 

25. An apparatus according to claim 19 wherein said 
output source files includes function files which are module 
source files for a DCOM Server apphcation. 

26. An apparatus according to claim 19 wherein inputs 
used to generate said output source files include a function 
template, Open/OLTP service names from an Open/OLTP 
application, said view file, a set of interface names and 
functions provided by the user through the query, and a set 
of Universal Unique Identifiers (UUIDs) produced by a 
UUID generator in an Open/OLTP gateway. 

27. In a data processing system having a Distributed 
Component Object Module (DCOM) environment con- 
nected to an enterprise On-line Transaction Processing 
(OLTP) system, a method for the interactive, simplified 
creation of functions needed to access OLTP services from 
a DCOM CUent apphcation, comprising the steps of: 

creating a service on said OLTP system, including the 
creation of service input and output view files; 

transferring said service input and output files from said 
OLTP system to said DCOM environment such that 
said service input and output view files can be accessed 
by a function builder utility; 

reading said service input and output view files and 
extracting interface information from said service input 
and output view files via said function builder utility; 

generating a set of source files that are compatible with 
said DCOM environment via said function builder 
utility; 

building a DCOM client apphcation within the DCOM 
environment which includes standard calls to said 
source files generated by said fiinction builder utihty; 
and 

compihng a set of IDL source files generated by said 
function builder utility with a Microsoft Interface Defi- 
nition Language (MIDL) compiler, such that a set of 
MIDL output files is created. 

28. A method according to claim 27 wherein said set of 
MIDL output files includes a proxy/stub source file that 
includes a proxy fiinction for the DCOM Client apphcation 
and a stub function for a DCOM Server. 

29. A method according to claim 27 vi^erein said set of 
MIDL output files inchides an interface Universal Unique 
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Identifier (UUID) source file that provides UUIDs for said 
DCOM client application. 

30. A method according to claim 27 wherein said set of 
MIDL output files includes a header file that is used in the 
conQpilation of said DCOM client application and server 
source code. 
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31. A method according to claim 27 wherein said set of 
MIDL output files include a Dynamic Link Library (DLL) 
data file that provides entry point information to a proxy/ 
stub function. 

***** 
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